Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/main/services/mcp-apps/service.test.ts:79-85
**Test asserts `resolves.toBeNull()` but the implementation now rejects**

`doFetchUiResource` re-throws connection failures instead of returning `null`. When there is no server config, `getOrCreateConnection` throws `Error: No server config for: posthog`, which is caught and re-thrown by `doFetchUiResource`. Neither `fetchUiResourceByUri` nor `getUiResourceByUri` has a `catch` block, so the promise rejects entirely. `expect(...).resolves.toBeNull()` asserts a *resolved* promise — this test will fail with a rejection error.

The test comment even describes the new intent ("boot-race failures as transient"), but the assertion is the opposite of that intent. It should be `rejects.toThrow(...)` to match the rethrow path, or the test needs to set up a server config so the connection succeeds.

### Issue 2 of 2
apps/code/src/shared/types/mcp-apps.test.ts:1-48
**Separate `it` blocks for one function — parameterised test preferred**

`resolveResultResourceUri` is called with five different inputs across separate `it` blocks, each testing a different input variant. Per the team's coding standard, this is the canonical case for `it.each` — a single parameterised test is easier to extend, makes the coverage matrix obvious at a glance, and avoids duplicating the `expect(resolveResultResourceUri(...))` call. The test that covers `undefined` already batches multiple cases on one assertion; the others could follow the same pattern (or consolidate into a table).